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Abstract 

A nexus is a tree that contains shared nodes, nodes that have more 
than one incoming arc. Shared nodes are created in almost every 
functional program—for instance, when updating a purely func¬ 
tional data structure—though programmers are seldom aware of 
this. In fact, there are only a few algorithms that exploit sharing of 
nodes consciously. One example is constructing a tree in sublinear 
time. In this pearl we discuss an intriguing application of nexuses; 
we show that they serve admirably as memo structures featuring 
constant time access to memoized function calls. Along the way 
we encounter Boolean lattices and binomial trees. 

Categories and Subject Descriptors 

D.l.l [Programming Techniques]: Applicative (Functional) Pro¬ 
gramming; D.3.2 [Programming Languages]: Language Clas¬ 
sifications —applicative (functional) languages', E.l [Data]: Data 
Structures —trees 

General Terms 

Algorithms, design, performance 

Keywords 

Memoization, purely functional data structures, sharing. Boolean 
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1 Introduction 

A nexus is a tree that contains shared nodes, nodes that have more 
than one incoming arc. Shared nodes are created in almost every 
functional program, though programmers are seldom aware of this. 
As a simple example, consider adding an element to a binary search 
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tree. Here is a suitable data type declaration for binary trees given 
in the functional programming language Haskell 98 [10]: 

data Tree a = Empty 

| Node{left :: Tree a, info:: alright:: Tree a} 
leaf :: Va. a ^ Tree a 

leaf x = Node Empty x Empty 

Here is the definition of insertion: 

insert :: Va. (Ord a) => a —* Tree a —> Tree a 

insert x Empty = leaf x 
insert x (Node l kr) 

| x < k = Node (insert xl)kr — r is shared 

\ otherwise = Node l k (insert x r) —/is shared 

Observe that in each recursive call one subtree is copied unchanged 
to the output. Thus, after an insertion the updated tree insert xt and 
the original tree t —which happily coexist in the functional world— 
contain several shared nodes. As an aside, this technique is called 
path copying [11] in the data structure community. 

Perhaps surprisingly, there are only a few functional programs that 
exploit sharing of nodes consciously [9]. For instance, sharing al¬ 
lows us to create a tree in sublinear time (with respect to the size of 
the tree). The call full n x creates a full or complete binary tree of 
depth n labelled with the same value x. 

full :: Va .Integer ^ a —> Tree a 

full Ox = leaf x 

full(n+\)x Nodetxt - t is shared 
where t » full n x 

The sharing is immediate: the result of the recursive call is used 
both for the left and for the right subtree. So is the sub-linearity: 
just count the nodes created! 

Now, why are nexuses not more widely used? The main reason is 
that sharing is difficult to preserve and impossible to observe, ex¬ 
cept indirectly in the text of the program by counting the number of 
nodes that are created. In a purely functional setting full is equiva¬ 
lent to the following definition which exhibits linear running time: 

full' :: Va. Integer —> a —> Tree a 

full'Ox = leafx 

full' (n+\)x = Node (full' n x) x (full! n x) 

Indeed, an optimizing compiler might transform full' to full via 
common subexpression elimination. Since sharing is impossible 
to observe, it is also difficult to preserve. For instance, mapping a 
function across a tree, fmapf t, does away with all the sharing. 



These observations suggest that nexuses are next to useless. This 
conclusion is, however, too rash. In this pearl, we show that nexuses 
serve admirably as memo structures featuring constant time access 
to memoized function calls. Since entries in a memo table are never 
changed—because they cache the results of a pure function—there 
is no need ever to update a memo table. Consequently and fortu¬ 
nately, maintaining sharing is a non-issue for memo tables. 

Remark 1 . Is a nexus the same as a DAG, a directed, acyclic 
graph? No, it is not. By definition, a nexus contains nodes with 
more than one incoming arc whereas a DAG may or may not have 
this property. By definition, a DAG may not be cyclic whereas a 
nexus may very well have this property (circularity being an ex¬ 
treme case of sharing). Finally, there is one fundamental difference 
between trees and graphs: a node in a tree has a sequence of suc¬ 
cessors, whereas a vertex in a graph has a set of successors. 


2 Tabulation 

A memo function [7] is like an ordinary function except that it 
caches previously computed values. If it is applied a second time 
to a particular argument, it immediately returns the cached result, 
rather than recomputing it. For storing arguments and results, a 
memo function usually employs an indexed structure, the so-called 
memo table. The memo table can be implemented in a variety of 
ways using, for instance, hashing or comparison-based search tree 
schemes or digital search trees [3]. 

Memoization trades space for time, assuming that a table look-up 
takes (considerably) less time than recomputing the corresponding 
function call. This is certainly true if the function argument is an 
atomic value such as an integer. However, for compound values 
such as lists or trees the look-up time is no longer negligible. Worse, 
if the argument is an element of an abstract data type, say a set, 
it may not even be possible to create a memo table because the 
abstract data type does not support ordering or hashing. 

To sum up, the way memoization is traditionally set up is to con¬ 
centrate on the argument structure. On the other hand, the structure 
of the function is totally ignored, which is, of course, a good thing: 
once a memo table has been implemented for values of type x, one 
can memoize any function whose domain happens to be x. 

In this pearl, we pursue the other extreme: we concentrate solely 
on the structure of the function and largely ignore the structure of 
the argument. We say ‘largely’ because the argument type often 
dictates the recursion structure of a function as witnessed by the 
extensive literature on foomorphisms [6, 1]. 

The central idea is to capture the call graph of a function as a nexus, 
with shared nodes corresponding to repeated recursive calls with 
identical arguments. Of course, building the call graph puts a con¬ 
siderable burden on the programmer but as a reward we achieve 
tabulation for free: each recursive call is only a link away. 

To illustrate the underlying idea let us tackle the standard example, 
the Fibonacci function: 

fib :: Integer —» Integer 

fibO =0 

fib 1 =■ i 

fib{n+ 2|# fib(n)+fib(n+ 1) 

The naive implementation entails an exponential number of recur¬ 
sive calls; but clearly there are only a linear number of different 


calls. Thus, the call graph is essentially a linear list—the elements 
corresponding to fib ( n),fib (n — 1),... ,fib (1 ),fib (0)—with addi¬ 
tional links to the tail of the tail, that is, from fib (n + 2) to fib (n). 
To implement a memoized version of fib we reuse the tree type of 
Sec. 1: the left subtree is the link to the tail and the right subtree 
serves as the additional link to the tail of the tail. 


memo-fib 
memo-fib 0 
memo-fib 1 
memo-fib (n + 2) 

where t 


Integer —> Tree Integer 
leaf 0 

Node (leaf 0) 1 Empty 
node t (left t) 
memo-fib (n + 1) 


The function node is a smart constructor that combines the results 
of the two recursive calls: 


node :: Tree Integer —> Tree Integer —> Tree Integer 

node l r = Node l (info l + info r) r 


We will use smart constructors heavily in what follows as they allow 
us to separate the construction of the graph from the computation 
of the function values. 


Now, the fib function can be redefined as follows: 

fib = info ■ memo-fib 

Note, however, that in this setup only the recursive calls are mem¬ 
oized. If fib is called repeatedly, then the call graph is built re¬ 
peatedly, as well. Indeed, this behaviour is typical of dynamic¬ 
programming algorithms [2], see below. 

In the rest of the paper we investigate two families of functions 
operating on sequences that give rise to particularly interesting call 
graphs. 


3 Segments 

A segment is a non-empty, contiguous part of a sequence. For in¬ 
stance, the sequence abed has 10 segments: a, b, c, d, ab, be, cd, 
abc, bed, and abed. An immediate segment results from removing 
either the first or the last element of a sequence. In general, a se¬ 
quence of length n has two immediate segments (for n> 2 and zero 
immediate segments forO < n < 1) and \n(n+ 1) segments in total. 

A standard example of the use of segments is the problem of 
optimal bracketing in which one seeks to bracket an expression 
x\ © X2 © • • • © x„ in the best possible way. It is assumed that 
is an associative operation, so the way in which the brackets are in¬ 
serted does not affect the value of the expression. However, brack¬ 
eting may affect the costs of computing the value. One instance of 
this problem is chain matrix multiplication. 

The following recursive formulation of the problem makes use of a 
binary tree to represent each possible bracketing: 

data Expr a = Const a \ Expr a :©: Expr a 
opt :: [ct] —> Expr a 

opt [x] = Const x 

opt xs = best [opt si :©: opt S2 \ (si,S2) <— uncat xs] 

The function best :: [Expr a] —> Expr a returns the best tree (its def¬ 
inition depends on the particular problem at hand), and uncat splits 
a sequence that contains at least two elements in all possible ways: 

uncat :: Va. [a] —> [([a],[a])] 

uncat [xi,x 2 \ = [([xi],[x 2 ])] 

uncat ( x:xs ) = ([ x\,xs):map (k(l,r) —» (x: l,r)) (uncat xs) 






Figure 1. Call graph of a function that recurs on the immediate 
segments. 


The recursive formulation leads to an exponential time algorithm, 
and the standard dynamic programming solution is to make use of 
a memo table to avoid computing opt more than once on the same 
argument. One purely functional scheme, a rather clumsy one, is 
developed on pages 233 to 236 of [1], However, using nexuses, 
there is a much simpler solution. 

Before we tackle optimal bracketing, let us first look at a related but 
simpler problem, in which each recursive call depends only on the 
immediate segments. 


right-hand side. 

Alternatively, the tree can be constructed in a top-down, recursive 
fashion: the triangle is created by adding a diagonal slice (corre¬ 
sponding to a left spine) for each element of the sequence. 

top-down :: [ct] —> Tree x 
top-down foldrl (o) • map leaf 

The helper function ‘o’ adds one slice to a nexus: its first argument 
is the singleton tree to be placed at the bottom, its second argument 
is the nexus itself. For instance, when called with leaf a and the 
tree rooted at bcde (see Fig. 1), ‘o’ creates the nodes labelled with 
abode, abed, abc, ab and finally places leaf a at the bottom. 

(o) :: Tree x —» Tree x —> Tree x 

tou@(Empty) = t 

tou@(Node Ixr) = node (tol) u 


Of course, since the smart constructor node accesses only the roots 
of the immediate subtrees, it is not necessary to construct the tree at 
all. We could simply define leaf = <p and node = (o). (In fact, this 
is only true of the bottom-up version. The top-down version must 
keep the entire left spine of the tree.) The tree structure comes in 
handy if we want to access arbitrary subtrees, as we need to do for 
solving the optimal bracketing problem. This is what we turn our 
attention to now. 


3.1 Immediate segments 

Consider the function/ defined by the following scheme: 

/ :: [o]->x 

f[x] = <px 

f xs | length xs> 2 = f (init xs) of (tail xs) 

where 9 :: a —> x and (o):: x —> x —> x. Note that init xs and tail xs are 
the immediate segments of xs. Furthermore, note that / is defined 
only for non-empty sequences. The recursion tree or call graph of 
/ for the initial argument abode is depicted in Fig 1. The call graph 
has the form of a triangle; the inner nodes of the triangle are shared 
since init ■ tail = tail ■ init. 


3.2 All segments 

The function opt is an instance of the following recursion scheme: 

/ :: [o]-»x 

f[x] ■ * ' cp-v 

/ xs I length xs> 2 m ]q [ (f s 1,/ s 2 ) \ (*t, *2) uncat xs] 

where 9:: 0 —> x and q:: [(x,x) ] —► x. The function q combines the 
solutions for the ‘uncats’ of xs to a solution for xs. 

Since the call tree constructed in the previous section contains all 
the necessary information we only have to adapt the smart construc¬ 
tor node: 


Now, let us build the recursion tree explicitly. We reuse the Tree 
data type of Sec. 1 and redefine the smart constructors leaf and 
node, which now take care of calling 9 and ‘o’. 

leaf :: a —*• Tree x 

leaf x = Node Empty (9 x) Empty 

node : : Tree x —> Tree x —> Tree x 

node l r = Node l (info l o info r) r 

The most immediate approach is to build the call tree in a bottom- 
up, iterative manner: starting with a list of singleton trees we re¬ 
peatedly join adjacent nodes until one tree remains. 


bottom-up 

:: [a]—>7>eex 

bottom-up 

= build ■ map leaf 

build 

:: [Tree x] —> Tree x 

build [f] 

= t 

build ts 

= build (step ts) 

step 

:: (Tree x] —> (Tree x] 

step [f] 

= H 

step (t\: t2 : ts) 

= node t\ t2 : step (t2 : ts) 


The last equation introduces sharing: t2 is used two times on the 


node : : Tree x —> Tree x —> Tree x 

node Ir = Node l (q (zip (Ispine l ) (rspine r))) r 


The ‘uncats’ of the sequence are located on the left and on the right 
spine of the corresponding node. 


Ispine, rspine 
Ispine (Empty) 
Ispine (Node Ixr) 
rspine (Empty) 
rspine (Node Ixr) 


Ma.Treea^ [a] 
[] 

Ispine l -H- [x] 

[] 

[x] -H- rspine r 


The functions Ispine and rspine can be seen as ‘partial’ inorder 
traversals: Ispine ignores the right subtrees while rspine ignores 
the left subtrees. (The function Ispine exhibits quadratic running 
time, but this can be remedied using standard techniques.) For in¬ 
stance, the left spine of the tree rooted at abed is a, ab, abc, and 
abed. Likewise, the right spine of the tree rooted at bcde is bcde, 
ede, de, and e. To obtain the uncats of abode, we merely have to zip 
the two sequences. 


Now, to solve the optimal bracketing problem we only have to de¬ 
fine 9 = Const and q = best ■ map (uncurry (:©:)). 



4 Subsequences 




A subsequence is a possibly empty, possibly non-contiguous part of 
a sequence. For instance, the sequence abed has 16 subsequences: 
e, a, b, c, d, ab, ac, ad, be, bd, cd, abc, abd, acd, bed, and abed. An 
immediate subsequence results when just one element is removed 
from the sequence. A sequence of length n has n immediate subse¬ 
quences and 2" subsequences in total. 


As an illustration of the use of subsequences we have Hutton’s 
Countdown problem [4]. Briefly, one is given a bag of source num¬ 
bers and a target number, and the aim is to generate an arithmetic 
expression from some of the source numbers whose value is as close 
to the target as possible. The problem can be solved in a variety 
of ways, see [8]. One straightforward approach is to set it up as 
an instance of generate and test (we are only interested in the first 
phase here). We represent bags as ordered sequences employing 
the fact that a subsequence of an ordered sequence is again ordered. 
The generation phase itself can be separated into two steps: first 
generate all subsequences, then for each subsequence generate all 
arithmetic expressions that contain the elements exactly once. 


data Expr 


exprs 

exprs 


Const Integer 

Add Expr Expr \ Sub Expr Expr 
Mul Expr Expr \ Div Expr Expr 
[Integer] —> [Expr] 
concatMap generate ■ subsequences 


generate :: [Integer] —> [Expr] 

generate [x] = [Const x] 

generatexs = [e \ (si,s 2 ) <—unmerge xs, 
ei <— generate s u 
e 2 <- generate s 2 , 
e <— combine e\ e 2 ] 

The function combine, whose code is omitted, yields a list of all 
possible ways to form an arithmetic expression out of two subex¬ 
pressions. The function unmerge splits a sequence that contains at 
least two elements into two subsequences (whose merge yields the 
original sequence) in all possible ways. 


unmerge 
unmerge [xi,X2] 
unmerge (x : xs) 


Va.[a] -> [{[a], [a])] 

[(M,[*2])l 

([x\,xs):map(X(l,r)^(l,x:r))s 
+\-map (k(l,r) —> {x:l,r)) s 
unmerge xs 


For instance, unmerge abed yields the following list of pairs: 
[ {a, bed), ( b, acd), {c, abd), {be, ad), {ab, cd), {ac, bd), {abc, d) ]. 


Now, how can we weave a nexus that captures the call graph of 
generate ? As before, we first consider a simpler problem, in which 
each recursive call depends only on the immediate subsequences. 


4.1 Immediate subsequences 


Consider the function/ defined by the following scheme: 


/ 

/[] 
/ M 

fxs 


[<T] —►T 
(0 
<px 

q [f s | s <— delete xs] 


where to:: x, (p:: c —> x, and q:: [t] —> x. The function c, combines 
the solutions for the immediate subsequences of xs to a solution for 



Figure 2. Call graph of a function that recurs on the immediate 
subsequences. 



lattice of Fig. 2. 


xs. The function delete yields the immediate subsequences. 

delete :: Va. [a] —> [[a]] 

delete [] — [] 

delete {x:xs) = map {x:) {delete xs)-H-[xs] 


The call graph of / for the initial argument abed is depicted in 
Fig. 2. Clearly, it has the structure of a Boolean lattice. Though 
a Boolean lattice has a very regular structure it is not immediately 
clear how to create a corresponding nexus. So let us start with the 
more modest aim of constructing its spanning tree. Interestingly, 
a spanning tree of a Boolean lattice is a binomial tree. Recall that 
a binomial tree is a multiway tree defined inductively as follows: a 
binomial tree of rank n has n children of rank n — 1, n — 2,..., 0. To 
represent a multiway tree we use the left child, right sibling repre¬ 
sentation. 1 Since it will slightly simplify the presentation, we will 
build the binomial tree upside down, so the subtrees are labelled 
with ‘supersequences’ rather than subsequences. 


top-down, tree 
top-down xs 



where l 


Va. [a] -> Tree [a] 

Node {treexs) [] Empty 

Node ' [x] r 

fmap (x:) {treexs) — child 
tree xs — sibling 


The binomial tree for the sequence abed is pictured in Fig. 3. Note 


Actually, a binary tree represents a forest of multiway trees, 
see [5], A single multiway tree is represented by a binary tree with 
an empty right subtree. 




that the left child, right sibling representation of a binomial tree is a 
perfectly balanced binary tree (if we chop off the root node). Now, 
it is immediate that each node in the left subtree l has an immediate 
subsequence in the right subtree r at the corresponding position. 
This observation is the key for extending each node by additional 
up-links to the immediate subsequences. In order to do so we have 
to extend the data type Tree first. 

data Tree a = Empty 

| Node{up::[Tree a], — up links 

left:: Tree a, — child 
info:: a, 

right :: Tree a } — sibling 

As usual, we introduce a smart constructor that takes care of calling 
tp and q. 

node :: [Tree x] —> Tree x —> a —> Tree x —> Tree x 

node [u\lxr = Node [u] l (<p x) r 

node usIxr = Node us l (q (map info us)) r 


Here is the revised version of top-down that creates the augmented 
binomial tree. 



Fig. 2. 


4.2 All subsequences 


The function generate is an instance of the following scheme: 


/ :: [o]-x 

/[] = © 

/ [x] = <?x 

fxs I lengthxs >2 = q [(fsi,fs 2 ) \ (si,*2) <- unmergexs] 


top-down :: [o] — >Tree% 

top-down xs = v 

where v ! 4§fc Node [ ] (tree xs v [ ]) to Empty 

The helper function tree takes a sequence, a pointer to the father 
and a list of pointers to predecessors, that is, to the immediate sub¬ 
sequences excluding the father. To understand the code, recall our 
observation above: each node in the left subtree l has an immediate 
subsequence in the right subtree r at the corresponding position. 


tree[\pps 
tree (x:xs)pps 

where v 


[o] —> Tree x —► [Tree x] —► Tree x 
node (p:ps) Ixr 

tree xsv (r: map left ps) — child 
tree xs p (map right ps) — sibling 


where ©:: x, cp:: a —> x, and q:: [ (x, x) ] —» x. The function q combines 
the solutions for the unmerges of xs to a solution for xs. 

Each node in the nexus created by top-down spans a sublattice of 
sequences. Since each recursive call of generate depends on all sub¬ 
sequences of the argument, we have to access every element of this 
sublattice. In principle, this can be done by a breadth-first traver¬ 
sal of the graph structure. However, for a graph traversal we have 
to keep track of visited nodes. Alas, this is not possible with the 
current setup since we cannot check two nodes for equality. Fortu¬ 
nately, there is an attractive alternative at hand: we first calculate a 
spanning tree of the sublattice and then do a level-order traversal of 
the spanning tree. 

As we already know, one spanning tree of a Boolean lattice is the 
binomial tree. Since we follow the up links, we use again the mul¬ 
tiway tree representation. 


The parent of the child l is the newly created node v; since we go 
down, /’s predecessors are the right subtree r and the left subtrees 
of v’s predecessors. The parent of the sibling r is u, as well; its 
predecessors are the right subtrees of v’s predecessors. The subtree l 
has one predecessor more than r, because the sequences in l are one 
element longer than the sequences in r (at corresponding positions). 

Do you see where all a node’s immediate subsequences are? Pick 
a node in Fig. 3, say ahd. Its parent (in the multiway tree view) 
is an immediate subsequence, in our example ab. Furthermore, the 
node at the corresponding position in the right subtree of the parent 
is an immediate subsequence, namely ad. The next immediate sub¬ 
sequence, bd, is located in the right subtree of the grandparent and 
so forth. 

To sum up, top-down xs creates a circular nexus , with links go¬ 
ing up and going down. The down links constitute the binomial 
tree structure (using a binary tree representation) and the up links 
constitute the Boolean lattice structure (using a multiway tree rep¬ 
resentation). Since the nexus has a circular structure, tree depends 
on lazy evaluation (whereas the previous programs happily work in 
a strict setting). 


AsdaRosea = Branch{label::a,subtrees:: [Rosea}} 
binom :: Vex. Int —> Tree a —> Rose a 

binom r (Node us -X _) 

= Branch x [binom i u \ (i, u) <— zip [0.. r — 1 ] us ] 

Given a rank r, the call binom r t yields the binomial tree of the 
nexus t. Note that the ranks of the children are increasing from left 
to right (whereas normally they are arranged in decreasing order of 
rank). This is because we are working on the upside-down lattice 
with the largest sequence on top, see Fig. 4. 

level-order :: Va. [Rose a] —> [a] 
level-order ts 

I null ts §l|[] 

| otherwise = map label ts 

-H-level-order (concatMap subtrees ts) 

As an example, the level-order traversal of the binomial tree shown 
in Fig. 4 is abed, abc, abd, acd, bed, ab, ac, ad, be, bd, cd, a, b, 
c, d, and e. Clearly, to obtain all possible unmerges we just have to 
zip this list with its reverse. 

The level-order traversal has to be done for each node of the nexus. 



As before, it suffices to adapt the smart constructor node accord¬ 
ingly: 


node [u\ lx 
node us lx 

where 


[Tree x] —> Tree x —> o —> Tree x —> Tree x 
Node [u] l (q>x) r 


Node us l (q (tail (zip (reversexs i) XS2))) r 
halve (level-order [binorn (length us) t]) 


Note that we have to remove the trivial unmerge (e,abcd) from the 
list of zips in order to avoid a black hole (using tail). The function 
halve splits a list into two segments of equal length. 
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